Elegir CMS: enterprise, headless o WordPress bien gobernado

Elegir CMS es una decisión de gobernanza, no de moda. WordPress bien gobernado, un CMS enterprise o una arquitectura headless resuelven problemas distintos: quién publica, en cuántos idiomas, con qué integraciones y quién lo mantiene dentro de tres años.

Este marco es para una conversación entre marketing y sistemas. No es una ranking de productos. En dobleO la decisión se toma en un workshop de discovery, con el equipo que va a vivir con el CMS después del lanzamiento.

En resumen

• Empieza por editores, roles, idiomas, integraciones y quién lo mantiene. El nombre del producto va después.
• WordPress es suficiente cuando el equipo editorial es el centro y la gobernanza de temas, plugins y despliegue está escrita.
• Headless o un CMS enterprise se justifican cuando hay muchos canales, una experiencia a medida muy separada del contenido, o requisitos de plataforma que el CMS habitual no cubre sin deuda.
• El riesgo habitual no es “elegir mal el logo”. Es el lock-in, la deuda de plugins y una accesibilidad que nadie posee.

La plataforma se decide dentro del diseño y desarrollo web, con marketing y sistemas en la misma mesa.

Cómo elegir CMS en un workshop de una mañana

El workshop no es una demo de tres productos. Es una reunión en la que marketing y sistemas contestan las cinco dimensiones con ejemplos del mes anterior, no con principios. Hace falta quien publica, quien integra y quien va a seguir operando el sitio. Si falta uno de los tres, el acta hay que marcarla como provisional.

Se empieza por una semana real del equipo editorial. Cuántas páginas se han publicado, cuántas han esperado aprobación, cuántas se han tenido que pedir a un proveedor porque el CMS no dejaba componerlas. Ese relato vale más que la frase “necesitamos flexibilidad”. Si el equipo publica fichas de producto que vienen de otro sistema, la flexibilidad que pide no es un constructor visual. Es una integración y una plantilla rígida. Confundir las dos cosas es la vía rápida hacia un CMS lleno de excepciones.

Idiomas, integraciones y quién lo opera

Después, los idiomas. Se coge una página que exista en dos lenguas y se mira si el contenido es el mismo, si una lengua tiene módulos que la otra no tiene, y quién traduce. Si el alemán no replica el árbol del español, un plugin de “idioma como copia” va a estorbar. Si todas las lenguas son calcos y las aprueba una sola persona, un único árbol con traducción basta. La arquitectura de contenido sale de esa comparación, no de la ficha comercial del producto.

Las integraciones se listan en dos columnas: las que esta fase tiene que dejar funcionando y las que solo hay que no impedir. “No impedir” significa modelo de contenido y URLs que puedan recibir el catálogo más adelante, no construir el conector ahora. Meter el conector “ya que estamos” sin entorno de pruebas ni dueño funcional es la tarea que se come el calendario.

La operación se cuenta en personas, no solo en licencias. ¿Hay alguien interno que actualice, o cada parche es un ticket al partner? ¿Cuántos proveedores conocen hoy el tema? Un WordPress gobernado con un tema propio y una lista corta de plugins puede ser más barato de operar que una plataforma con licencia enterprise si el equipo que la sabe usar no está. Al revés, una licencia que ya está pagada y un equipo formado no se tira porque un rediseño prefiera otra estética de backoffice.

Tres situaciones frecuentes, y por qué no se resuelven con el mismo producto

Primera. Un equipo editorial de pocas personas publica a diario en dos idiomas que son calco. El contenido vive en la web. El CRM recibe el formulario y nada más. No hay app. Aquí un WordPress gobernado suele bastar: tema mantenido, bloques del sistema, roles, despliegue. Headless añadiría un front y una previsualización que ese equipo no ha pedido. Enterprise añadiría una licencia y un modelo de operación que nadie interno conoce. La tentación de “ya que rediseñamos, modernizamos la plataforma” se contesta con la semana real del editor, no con el ciclo de noticias del software.

Cuando el contenido sale en más de un canal

Segunda. El mismo contenido tiene que salir en la web, en una aplicación y en un portal de partners, y el equipo de producto ya tiene un front propio. El CMS es la fuente del texto, no de la página. Headless puede tener sentido si el editor previsualiza de verdad y si hay quien mantenga el contrato entre modelo y front. Si la previsualización es un JSON que solo entiende desarrollo, el time-to-publish empeora aunque la arquitectura sea más “moderna”. En el workshop se pide ver esa previsualización con una página del cliente, no con el contenido de demostración del fabricante.

Tercera. Varias sociedades, aprobaciones largas, idiomas que no se calcan y un requisito de auditoría sobre quién publicó qué. A veces eso ya está resuelto en el CMS que la empresa paga. El rediseño es de plantillas y de gobernanza, no de mudanza. Mudar porque el backoffice parece antiguo traslada años de roles y de integraciones a un proyecto que se vendió como visual. Eso aparece en el mes seis, cuando las filiales no pueden publicar. Conviene que eso quede escrito en la página que sale del workshop, no en el parte de incidencias.

En las tres se escribe la arquitectura y la infraestructura: cómo se despliega, cómo se separan entornos, qué pasa con la caché y con el rendimiento de las plantillas en la opción elegida. El workshop no impone una herramienta. Sirve para que marketing y sistemas salgan con una frase que compras pueda leer sin volver a ver la demo.

WordPress gobernado, en decisiones concretas

Gobernar no es instalar un cortafuegos y dar por cerrada la seguridad. Es un conjunto pequeño de reglas que el proyecto deja escritas.

El tema lo mantiene el equipo que desarrolla. No se concede un constructor ilimitado en el que cada editor compone la home con bloques que cargan su propio script. Los bloques permitidos son los del sistema de diseño. Añadir un bloque nuevo es un cambio de sistema, con revisión de rendimiento y de accesibilidad, no una opción del menú.

Los plugins tienen dueño y motivo. Cada uno responde a una capacidad que el tema no debe reinventar mal —idiomas, formularios, redirecciones— o no está. Las actualizaciones tienen entorno. Producción no es el lugar donde se comprueba si un plugin sigue siendo compatible.

Los roles separan quien redacta, quien publica y quien administra. La cuenta de administrador no se comparte con la agencia de medios ni con el becario que “solo va a poner un píxel”. El píxel, si legal lo ha autorizado, entra por el cauce de etiquetas, no por un plugin pegado en una tarde.

El rendimiento de las plantillas tiene umbral, como en cualquier otra plataforma. WordPress no es lento por ser WordPress. Se vuelve lento cuando el tema, los plugins y los terceros se suman sin que nadie reste. Esa resta es parte del proyecto, no una fase de optimización que se encarga cuando ya se ha salido del presupuesto.

Qué cambia en el rendimiento y en el despliegue según cómo se renderiza

Elegir CMS no es elegir un logo. Es elegir dónde se produce el HTML, quién invalida la caché y qué ve el editor cuando pulsa previsualizar. Esas tres respuestas separan un WordPress gobernado, un CMS enterprise y un front desacoplado mejor que la demo comercial.

Tema clásico

En un tema clásico, el HTML sale del servidor cuando se pide la página, a menudo desde una caché de página completa en el CDN o en el propio servidor. Publicar es invalidar esa URL —o la etiqueta de caché de esa plantilla— y dejar que la siguiente petición regenere. El editor previsualiza en el mismo sistema. El riesgo de rendimiento está en el HTML que no se puede cachear (porque varía por cookie de sesión o por un módulo personalizado), en las consultas que se hacen en cada miss de caché, y en el JavaScript que el tema añade encima. Un objeto en Redis y un opcode cache aceleran el miss. No arreglan un hero de cuatro megabytes. En la infraestructura se anota qué respuesta lleva Cache-Control público, cuál lleva private porque hay sesión, y cómo se purga al publicar sin vaciar todo el dominio.

En un modelo que genera HTML estático, o que lo regenera por incrementos, la página puede ser un archivo en el CDN y el TTFB baja porque no hay aplicación en el camino. Publicar es un build o una regeneración de esas URLs. El editor espera a ese build para ver la página de verdad. Si el build dura lo que dura un sitio de cientos de plantillas y varios idiomas, el time-to-publish empeora aunque el laboratorio de la home sea excelente. La previsualización de un borrador exige un camino distinto al de la página cacheada: un token, un servidor de preview, o aceptar que el editor no ve lo que verá el público. Ese camino se prueba en el workshop con una página real, no con el contenido de ejemplo del fabricante.

Front desacoplado e invalidación

En un front desacoplado, el CMS guarda el modelo y una API lo sirve. El HTML lo pinta otro sistema. Puede pintarlo en el servidor, en el build o en el navegador. Pintarlo solo en el navegador deja el primer HTML casi vacío: el LCP espera a JavaScript, y un rastreo que no ejecute bien ese JavaScript ve poco. Por eso “headless” no es una estrategia de rendimiento. Es una frontera. El rendimiento depende de que el HTML útil llegue en la primera respuesta, de que la API no se consulte en cada petición sin caché, y de que un fallo de la API no deje la portada en blanco. La previsualización es el punto que suele romperse: el editor guarda en el CMS y el front sigue mostrando la versión publicada, o muestra un JSON. Si en el workshop nadie abre un borrador y ve la plantilla, la opción no está lista, por muy limpia que sea la arquitectura en el diagrama.

La invalidación es el detalle que compras no ve y que operaciones va a vivir. Purgar por URL concreta escala mal cuando un cambio de menú afecta a todo el sitio. Por etiqueta de plantilla (home, servicio, artículo) la purga es más precisa. Purgar el dominio entero en cada publicación es sencillo y esconde un sitio que no sabe qué ha cambiado. En los tres modelos hace falta la misma frase: qué acción del editor provoca qué purga, y en qué entorno se ha probado. También hace falta que las páginas con sesión no entren en la caché pública. Un área de clientes cacheada “porque así va más rápida” sirve a una persona el HTML de otra. Eso no es un ajuste. Es un defecto de arquitectura.

El modelo de contenido

El modelo de contenido se escribe al lado. Campos con nombre —titular, resumen, cuerpo, componente de prueba, formulario— frente a un único HTML pegado. Los campos viajan a otro front si algún día hay que salir. El HTML pegado no. Los idiomas son dos árboles de esos campos, no un plugin que duplica la URL sin hreflang. En la misma página quedan el render, la caché, la purga, los entornos y los secretos de la API fuera del repositorio público. El workshop no impone la herramienta que dobleO usa más a menudo. Sirve para que marketing y sistemas salgan pudiendo decir, en una frase, dónde nace el HTML, cuánto tarda el editor en verlo y qué se rompe si el partner que montó el tema o el front no sigue.

Riesgos que hay que nombrar

• Lock-in. Un front imposible de mover, un tema que solo conoce un proveedor, o un modelo de contenido tan específico que migrar equivale a reescribir.
• Deuda de plugins o módulos. Cada extensión es una superficie de actualización y de seguridad. La lista corta es parte del diseño.
• Accesibilidad. El CMS no la garantiza. La garantizan las plantillas, los componentes y un criterio de aceptación. Si no está en el alcance, no aparece el día de la auditoría interna.
• Previsualización y editores. En headless, si el editor no puede previsualizar, el equipo publica a ciegas o pide un doble trabajo. Eso hay que verlo en el workshop, no en el manual.

Preguntas frecuentes

¿Headless es siempre más rápido?

No. El rendimiento lo deciden el front, las imágenes, las fuentes y los terceros. Un headless mal construido es tan lento como un tema sobrecargado.

¿Se puede cambiar de CMS en el mismo proyecto que el rediseño?

Sí, si el cambio está en el alcance y hay inventario. Hacerlo “ya que estamos” a mitad del diseño es otra fase, no un detalle.

¿Quién debe estar en el workshop?

Quien publica, quien integra y quien va a mantener. Marketing solo, o sistemas solo, produce una decisión que el otro departamento deshace.

Siguiente paso

La plataforma elegida se mide en las plantillas que concentran visitas y conversiones, antes de cerrar el diseño.

Forma parte del desarrollo web, no de una optimización posterior.

Siguiente en este ciclo: Core Web Vitals antes del rediseño.

Diego Quiñones · Technical Growth Architect en dobleO (Madrid). Arquitectura web, rendimiento, SEO técnico e infraestructura, junto al equipo de diseño, SEO y SEM, cuentas y dirección. Con el equipo dobleO.